A major reason for the high cost of test equipment is the specialized nature of conventional tester architecture. Each tester manufacturer has a number of tester platforms that are not only incompatible across companies, but also incompatible across platforms. Because of these incompatibilities, each tester requires its own specialized hardware and software components that cannot be used on other testers.
Because of the dedicated nature of conventional tester architecture, all hardware and software must remain in a fixed configuration for a given tester. To test an IC, a dedicated test program is developed that uses some or all of the tester capabilities to define the test data, signals, waveforms, and current and voltage levels, as well as to collect the device under test (DUT) response and determine DUT pass/fail.
To increase flexibility and lower the cost of test systems, it would be desirable to connect and use test modules from multiple vendors while testing ICs. However, because of the specialized and proprietary nature of the hardware and software in each vendor's test modules, heretofore it has been difficult or impossible to plug-in and use the test modules from multiple vendors.
In response to this need, an open architecture test system has been developed that allows plug and play of different modules from different vendors. This open architecture test system allows reconfigurability and scalability of the system in terms of number and type of DUTs and test modules.
A block diagram of a high level perspective of an open architecture test system 100 is illustrated in FIG. 1. In FIG. 1, the modules 102 may be functional units such as a digital pincard, and analog card, a device power supply (DPS), or instruments such as a waveform generator. The physical connections to the modules 102 may be obtained through a module connection enabler 104 that includes a switch matrix network 106. The switch matrix network 106 may include logic, traces, and pins. The system controller 108 is typically the point of interaction for a user. The system controller 108 provides a gateway to the site controllers 110 and synchronization of the site controllers 110 in a multi-site/multi-DUT environment. The system controller 108 and multiple site controllers 110 may operate in a master-slave configuration. The system controller 108 controls the overall system operation and determines that functions that a particular site controller 110 should perform. Each site controller 110 is itself sufficient to test a DUT 112. The site controller 110 controls and monitors the operation of various modules 102 within a test site 114. A test site 114 is a collection of modules 102 that service the testing of a single DUT 112. A site controller 110 can control one or multiple test sites 114.
The overall platform consists of a hardware and software framework that provides interfaces through which various hardware and software modules can be employed. The architecture is a modularized system with module control software and a communication library that allows module-to-module, site controller to module, site controller-to-site controller, and system controller to site controller communication.
The open architecture test system allows different vendor hardware and software to be developed, certified and integrated reliably into the test system. The open architecture test system allows deployment of test modules in a plug-and-play manner. Each test module may be replaced with another test module from a different vendor. The only restriction is that each test module must follow the interface requirements of the integrating framework. Thus, vendor hardware could be any functional unit, such as a digital pin card, an analog card, a device power supply (DPS), etc.
Because the timing and interaction of modules in a test site may be critical to performing an accurate test of the DUT, there is a need to provide for the synchronization of the modules testing the corresponding DUT.